There is an increasing appreciation for the need for aesthetics and ease of use in the design of user interfaces (“UI”) to encourage use of computer applications and reduce frustration. To term the new user interfaces design strategies in cutting edge software as being “ergonomic” is not an overstatement. Such interfaces are a combination of functionality coded in the application and supported by the underlying platform, which may be an operating system (“OS”). Thus, the OS provides significant support for realizing an effective UI, and such support is an important factor in the competition between different OS available in the market.
Application programs are typically written for execution on a particular platform. Such a platform may be defined by a virtual machine offering a relatively invariant context regardless of the underlying hardware or an OS that is tied down to a particular hardware platform or even an application providing an execution context for another application, e.g., a plug-in module. The platform includes a plurality of services and appropriate management strategies to allow different applications access to system resources. These services provide many of the functions that applications are expected to use and thus free the application writer from worrying about the more mundane implementation details such as security, reading and writing data, managing memory resources, and I/O functions. Not surprisingly, this is an effective strategy since the services provided by the OS are used repeatedly. Having a single coherent implementation reduces complexity and enhances design of stable computing systems capable of executing different applications.
OS for computers, and for personal computers in particular, have undergone many changes. These changes not only improve the range of services available to applications, typically through an Application Programming Interface (API), but also provide new architectures that reduce the likelihood of crashing the entire computer system due to errors including those ascribable to applications or users. An important advance in designing stable computing systems has been the development of multithreaded systems, which are described further below.
Traditional OSs for personal computers used a single threaded architecture in which programming code was executed in a serial fashion. Any step or sequence of steps could result in a fatal bottleneck. A user is often hard-pressed to distinguish delays from a system failure. An improvement was a computing environment where if a busy application, as opposed to a non-functional application, could indicate that it was busy to the user, or preferably relinquish control to the OS to allow other applications and tasks to execute before being granted control again. Such computing environments were at the mercy of a well-behaved and cooperative application.
In contrast, in a multithreaded architecture the OS exercises greater control over the execution of different tasks. The OS schedules slices of time on the processor for identified units termed threads. A thread is a path of execution within a process that is recognized and provided time on the processor by the OS. Each application usually has at least one thread and, thus, is assigned time in accordance with its relative priority. Additionally, often an application executes in its own address space, particularly if it is treated as a process by the OS. This results in isolation of different processes from each other and contributes to greater system stability and robustness even when executing faulty applications.
It should be understood that the term thread refers to code that is provided execution time slices by an external entity, e.g., the OS. This does not foreclose a developer of an application to define a path of execution within the application such that the application directly controls the time allocated to a particular path while the OS may be unaware of its existence. For clarity, such developer defined execution paths are referred to as “fibers” as opposed to threads. The benefit in using threads is that, even if an application is defective it cannot hold up rest of the computing system, since it never has exclusive control of the computing environment. However, this statement should not be interpreted to imply that rogue applications designed to subvert the OS are not possible in a multithreaded computing environment. Accordingly, for conceptual convenience, threads may be generalized to scheduled code paths.
At least one of the threads assigned to an application is termed its main thread and typically implements the UI for the application. Modern UIs are usually graphical interfaces formed by a plurality of elements termed window elements or just windows. These window elements, controlled by the threads in a system, are displayed to a user. The display space available on the desktop is referred to as “real estate.” The desktop is typically implemented with the help of routines such as paint( ) to continually update it to reflect the current state and order of the windows displayed on it. A desktop thread, which is a system thread, manages painting of the desktop windows and also handles miscellaneous system events. Some windows that are fully or partially occluded by other windows may not be displayed in their entirety. The window in the foreground commands the attention of the user and has focus. Usually, the focus shifts as other windows are selected to be in the foreground.
Since window elements are not only output symbols but also aid in the input of events, each thread managing a window element is required to have a message loop. This loop allows messages to be sent for handling by the window element on the desktop. Similarly, messaging allows processing of input events by the OS, the application program or even the user by presenting them in an orderly fashion.
In addition, user input to the computer system is received from the hardware devices via a thread termed the raw input thread (RIT). The OS sorts the input events such as keystrokes, mouse movements, mouse clicks and the like in the RIT queue and forwards them to the appropriate application input thread queues or OS routines for handling. Input events are usually posted to an application owning the window element in focus. Furthermore, not all events are handled with the same priority. Some events, e.g., key combinations such as Alt-Tab keys shift focus from one window to another and are handled out of turn. Since each application has its own input queue, the failure of an application to handle its own queue entries is not fatal. In other words, it does not “hang” the entire system by making it unresponsive to further inputs.
The OS also provides implementation code for a variety of graphical objects and windows for use by application programs. This not only saves creators of applications the complex task of writing graphical code, but also promotes standardization of the UI. An example of such an interface is the familiar window interface in the “WINDOWS®” OSs manufactured by the “MICROSOFT®” Corporation of Redmond, Washington. The interface includes an enclosing rectangle, system buttons for closing, maximizing or restoring the window element, and an enclosed area that is available to the application/user to display arbitrary graphical or text symbols. The enclosing rectangle edges and corners are also usable for resizing the rectangle with the use of a pointing device such as the familiar mouse. Other designs for UIs are also possible along with modifications to the familiar designs, e.g., by varying color schemes/designs, transparency and other properties.
As described previously, the desktop displays window elements in accordance with an ordering termed Z-ordering. Z-ordering identifies the window in the foreground and the various other windows on a tree structure. This tree structure is suitably manipulated when a different window is moved to the foreground, possibly due to a change in focus due to a user clicking on another window and consequently transferring focus. Such transfer of focus can also results in another application or thread getting the input events from the RIT.
It is possible for an application to hang, and at the very least give the user the impression of being non-responsive, if an application fails to process its input queue. For instance, ordinarily the main thread of an application manages its windows. Thus, if the main thread of the application is occupied by a task then the entire application may appear to hang, i.e. be non-responsive. The area on the desktop, i.e., the real estate, occupied by window elements controlled by its main thread appears to be frozen. A user may find it difficult to close or manage such an application and may, indeed, lose significant control over the apparently frozen system. Even a mere delay may result in a drastic action being taken by many a user such as rebooting the system leading to possible loss of data and even damage to the file structure and the hardware.